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(57) Abstract: A system and method are provided for integrating a voice gateway system to incorporate an IP/PBX telephone system 
(33). The system includes a public switched telephone network (PSTN 2), an internet protocol (IP) network (1), and a gateway 
network (30) coupled to the PSTN and to the IP network to route a telephone call over the PSTN or the IP network. The gateway 
network has a gateway server (31) coupled to the PSTN (2) and the IP network (1) and coupled to an IP/PBX telephone system 
(33). The gateway server (3 1) is configured to autamarically select over which of the IP network (1) or the PSTN (2) to route a calL 
Preferably, the system includes a number of gateway networks (10, 20, 30) coupled to one another via the IP Network (1) and the 
PSTN (2). In one embodiment, a gateway network (10) includes a PBX telephone system (12) having a voice mail server (32), and 
the gateway networks (10, 20, 30) are configured to provide voice mail service to a user of an IP telephone (41). 
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METHOD AND APPARATUS FOR INTEGRATING A VOICE GATEWAY 
WITH AN EP/PBX TELEPHONE SYSTEM 

5 

Cross Reference to Related Applications 

1 0 This application claims priority from United States Provisional Patent Application 

Serial Number 60/143,817 filed July 14, 1999. 

Field 

The present invention relates generally to communication systems and in particular 
15 to a hybrid communication system that integrates an IP/PBX telephone system with a 
communication system having an internet protocol (BP) network to and a public switched 
telephone network (PSTN) provide unified voice-mail to users of IP telephones. 

Background 

20 Telephony, that is voice communication over an internet protocol (IP) network, 

has gained rapidly in popularity in recent years among both businesses and individuals 
seeking to minimize the cost of the long distance telephone calls. IP telephony systems 
are described in, for example, commonly assigned co-pending U.S. Patent application 
serial number 09/061,802, which is incorporated herein by reference. An DP telephony 

25 system typically includes an IP network, such as a wide area network (WAN), a local area 
network (LAN), or the Internet, with a number of IP telephones connected thereto. The 
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IP telephones can be a stand-alone IP telephone directly connected to the EP network, or 
a computer workstation with a speaker, microphone and IP telephony software to function 
as an IP telephone. In addition, the IP telephone can be coupled to the public switched 
telephone network (PSTN) through a voice gateway that translates between data packets 
used by IP networks and analog signals used by the PSTN. 

One of the problems with current telephony systems, particularly for business 
users, is their inability to integrate with existing communication networks, such as a 
private branch exchange (PBX). PBXs, which are well-known and widely used within 
government and industry, are telecommunications switching systems maintained at one 
or more user sites that are used to connect internal station to station telephone calls and 
to the PSTN. In addition, many PBXs provide the users with advanced features such as 
caller ID, call forwarding, call conferencing, and voice-mail etc. These features have 
come to play a vital role in business, enabling the users to remain in contact with and 
better serve their clients and customers. The IP telephones of conventional telephony 
systems do not connect to a PBX at all, coupling instead to the PSTN through a gateway 
server, as described above, therefore these advance features are not available to users of 
IP telephones. Moreover, those systems that do couple to a PBX , as for example taught 
in U.S. Patent No. 5,867,494, to Krishnaswamy et al, merely teach a voice trunk through 
which voice and touch-tone (DTMF) signals may be bridged between an IP network and 
the PSTN via the PBX. Such a path cannot alone function to enable an IP telephone user 
to access the advanced features of the PBX. Thus, there is a need for an IP telephony 
system capable of being integrated with conventional existing PBX systems, to make the 
advanced features of the PBX available to IP telephone users. 

Summary 

The present invention relates to an apparatus and method for integrating a voice 
gateway system to incorporate an IP/PBX telephone system. This enables users of IP 
telephones to access many of the features of the gateway network. 

It is an object of the invention to provide an integrated voice gateway system 
which provides both PBX telephone users and IP telephone users with a common voice- 
mail system, which supports voice-mail feature transparency for all of the telephone users. 
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It is an object of the invention to provide an integrated voice gateway system with 
an EVPBX telephone system, where the IP telephones of the EP/PBX telephone network 
are used typically by the employees within a company. This gateway system can route a 
voice telephone call between parties at two different locations over a WAN IP network, 
5 where either or both parties are using a PBX telephone or an IP telephone. It is a further 
object of the invention that the gateway system will automatically select which of the IP 
network or PSTN over which to route the calls. 

It is a further object of the invention to provide a system which can route a 
telephone call between a calling party using an IP telephone at a first location within the 
1 0 system to a second location within the system via a WAN BP network, and then from the 
second location to a called party at a third location via the PSTN. 

It is an object of the invention to provide an integrated voice gateway system 
which can place a telephone call over an IP network, and then if, during the telephone 
call, the quality of the telephone call falls below a predetermined quality level, and the 
1 5 quality degradation is determined to be due to the WAN DP network performance, to be 
able to reroute the telephone call over to the PSTN, and to do so in a manner that is 
transparent to both the calling and called parties, either or both of which can be using an 
IP telephone. 

It is an object of the invention to provide an integrated voice gateway system 
20 which can track any modifications to a profile of any telephone user in the enterprise. A 
telephone user includes users of PBX telephones and IP telephones. Modifications to the 
telephone user profile may include changes to the existing data for a user, addition of new 
users, and deletion of users. It is a further object of the invention to provide an integrated 
voice gateway system which can integrate with an enterprise directory to allow single 
25 point of entry for user profile modifications and to provide replication of these changes 
across all enterprise sites. 

It is an object of the invention to provide an integrated voice gateway system in 
which the identification of the calling party (e.g., name, title, department, primary 
telephone number) can be displayed on the called telephone's display, where the called 
30 party is using an IP telephone, and said telephone supports caller ID display. Likewise, 
the identification of the calling party can be displayed on any other telephone in the 
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integrated voice gateway system, where the calling party is using an IP telephone. In 
addition, the format of the displayed caller ID information is the same for all said 
telephones. 

It is an object of the invention to provide an integrated voice gateway system in 
5 which the identification of the calling party (e.g., name, title, department, primary 
telephone number) is displayed on a computer screen (rather than on a telephone display) 
co-located with the called party's telephone, and that such information be displayed 
regardless of the vendors) supplying the telephone equipment used by the calling and 
called parties. Either or both of the calling and called parties may be using an IP 

1 0 telephone. It is further an object of the invention that such information be provided 
regardless of the desktop workstation or PC (workstation and PC are referred to 
interchangeably herein), or operating system used via a WWW browser interface. 

It is an object of the invention to provide an integrated voice gateway system 
which can create a log of incoming telephone calls and call attempts arriving over a WAN 

15 IP network, and of outgoing telephone calls and call attempts routed over the WAN IP 
network, and identify the names of calling and called parties. It is a further object of the 
invention to provide a log of all incoming and outgoing calls whether the calling and 
called parties are using a PBX telephone, using a PSTN telephone, or using an IP 
telephone. 

20 It is an object of the invention to provide an integrated voice gateway system in 

which, when a called party's telephone is busy, the system can automatically set up a call 
between the calling party and the called party as soon as the called party hangs up, and 
either or both of calling party and called party can be using a IP telephone. It is a further 
object of the invention to provide such a capability even when a called party has voice- 

25 mail. 

It is an object of the invention to provide an integrated voice gateway system in 
which, when a called party is busy, the calling party may send a computer message which 
will be immediately displayed on a computer screen co-located with the called party's 
telephone, for example to explain why the calling party needs to speak with the called 
30 party, and one or more of the parties are using an IP telephone. 

It is an object of the invention to provide an integrated voice gateway system in 
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which, when a called party does not answer an incoming telephone call, the calling party 
may forward the call, for example to voice mail, or to an answering station (e.g. a 
receptionist or other designated party), and the calling party and/or the called party can 
be using an IP telephone. It is further an object of the invention to provide the capability 
5 for a party at an answering station to send a computer message which will immediately 
be displayed on a computer screen co-located with the called party's telephone. 

It is an object of the invention to provide an integrated voice gateway system in 
which a user of the system may set up the system to forward that user's telephone calls 
to a different telephone. It is a further object of the invention to forward calls to a PSTN 

1 0 telephone, a cellular telephone in a public wireless network, an IP telephone, a PC-based 
IP telephone, or a private mobile telephone. It is a further object of the invention to 
provide the capability for a user to set up the system to forward that user's telephone calls 
to different telephones according to a time schedule predetermined by the user. It is a still 
further object of the invention to provide the capability for a user to set up the system to 

1 5 forward telephone calls originating only from one or more calling parties so designated 
by the user. It is a further object of the invention to provide the capability to setup call 
forwarding via a browser interface or interactive voice response (IVR). 

Brief Description of the Drawings 

20 These and various other features and advantages of the present invention will be 

apparent upon reading of the following detailed description in conjunction with the 

accompanying drawings, where: 

FIG. 1 is a schematic diagram showing an embodiment of high-level network 

architecture for various gateway network configurations; 
25 FIG. 2 is a schematic diagram showing an embodiment of a gateway network 

configuration which includes a gateway server, a PBX telephone system and an IP/PBX 

telephone system; 

FIG. 3 A is a schematic diagram showing call routing for a telephone call made 
between a PSTN telephone and an IP telephone in the same locale according to an 
30 embodiment of the present invention; 

FIG. 3B is a schematic diagram showing call setup sequence for a telephone call 



WO 01/06740 



PCT/US00/19209 



made from an EP telephone to a PSTN telephone along the route shown in FIG. 3 A; 

FIG. 3C is a schematic diagram showing call setup sequence for a telephone call 
made from a PSTN telephone to an IP telephone along the route shown in FIG. 3 A; 

FIG. 4A is a schematic diagram showing call routing for a telephone call made 
5 between a PBX telephone and an IP telephone in the same locale according to an 
embodiment of the present invention; 

FIG. 4B is a schematic diagram showing call setup sequence for a telephone call 
made from an IP telephone to a PSTN telephone along the route shown in FIG. 4A; 

FIG. 4C is a schematic diagram showing call setup sequence for a telephone call 
1 0 made from a PBX telephone to an IP telephone along the route shown in FIG. 4A; 

FIG. 5 A is a schematic diagram showing call routing for a telephone call made 
between one EP telephone and another IP telephone in the same locale according to an 
embodiment of the present invention; 

FIG. 5B is a schematic diagram showing call setup sequence for a telephone call 
1 5 made from one IP telephone to another IP telephone along the route shown in FIG. 5 A; 

FIG. 5C is a schematic diagram showing an alternate call setup sequence for a 
telephone call made from one IP telephone to another IP telephone along the route shown 
in FIG. 5A; 

FIG. 6A is a schematic diagram showing call routing for a telephone call made 
20 between a PSTN telephone and an IP telephone, with the two telephones in different 
locales according to an embodiment of the present invention; 

FIG. 6B is a schematic diagram showing call setup sequence for a telephone call 
made from an IP telephone to a PSTN telephone along the route shown in FIG. 6A; 

FIG. 6C is a schematic diagram showing call setup sequence for a telephone call 
25 made from a PSTN telephone to an IP telephone along the route shown in FIG. 6A; 

FIG. 7A is a schematic diagram showing call routing for a telephone call made 
between a PBX telephone and an IP telephone, with the two telephones in different 
locales according to an embodiment of the present invention; 

FIG. 7B is a schematic diagram showing call setup sequence for a telephone call 
30 made from an EP telephone to a PBX telephone along the route shown in FIG. 7A; 

FIG. 7C is a schematic diagram showing call setup sequence for a telephone call 
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made from a PBX telephone to an BP telephone along the route shown in FIG. 7A; 

FIG. 8A is a schematic diagram showing call routing for a telephone call made 
between one IP telephone and another IP telephone, with the two telephones in different 
locales according to an embodiment of the present invention; 
5 FIG. 8B is a schematic diagram showing call setup sequence for a telephone call 

made from one IP telephone to another IP telephone along the route shown in FIG. 8A; 

FIG. 9A is a schematic diagram showing call routing for a voice-over-IP telephone 
call made between a PBX telephone at one locale and an IP telephone at another locale 
according to an embodiment of the present invention; 
1 0 FIG. 9B shows the telephone call from FIG. 9A after it has been automatically re- 

routed over the PSTN instead of over the WAN IP network, due to degradation in the 
quality of service over the WAN; 

FIG. 1 OA is a schematic diagram showing call setup sequence for a telephone call 
made from a PBX telephone to an IP telephone at that same locale, where a caller using 
15 the PBX telephone is redirected to a called party's voice-mail system, due to lack of 
availability of the called party at the time the call is made; 

FIG. 1 OB is a schematic diagram showing call routing resulting from the call setup 
sequence of FIG. 10A, where the caller has been successful directed to the called party's 
voice-mail system at the same locale; 
20 FIG. 1 1 A is a schematic diagram showing call routing resulting from the call setup 

sequence for a telephone call made from a PBX telephone to an IP telephone at another 
locale, where the caller has been successful directed to the called party's voice-mail 
system; 

FIG. 1 IB is a schematic diagram showing call setup sequence for a telephone call 
25 made from the PBX telephone at one locale to the called party's voice-mail system at 
another locale along the route shown in FIG. 1 1 A; 

FIG. 12 shows how the gateway server polls the voice-mail system at regular 
intervals (the interval being configurable) in order to be able to keep the IP telephone 
users' telephones current with regard to whether the voice-mail light on the phone is on 
30 or off; 

FIG. 13A is a schematic diagram showing call routing for a telephone call made 
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between a PBX telephone and an IP telephone at the same locale; 

FIG. 13B is a schematic diagram showing call routing for a telephone call made 
between the PBX telephone and an IP telephone at another locale - the condition existing 
following the call transfer operation on the part of the IP telephone being used in FIG. 
5 13 A; 

FIG. 13C is a schematic diagram showing call setup sequence for transferring the 
telephone call from the route used in FIG. 13A to the route shown in FIG. 13B; 

FIG. 14 is a schematic diagram showing call routing for a 3-way conference call 
between a first party at a PBX telephone at a first locale, a second party at an IP telephone 
10 at a first locale, and a third party at an EP telephone at a second locale; and 

FIG. 15 is a schematic diagram showing call setup sequence for a telephone call 
made from an IP telephone to a PBX telephone at the same locale, where the call dialing 
operation was initiated via a browser-based GUI that is associated with the DP telephony 

1 5 Detailed Description 

FIG. 1 schematically illustrates an enteiprise network according to an embodiment 
of the present invention for passing voice and data communication between a number of 
different sites within an enterprise or company. The enterprise network typically includes 
one or more gateway networks, three which are shown, each having a gateway server, and 

20 a PBX telephone system, and/or an IP/PBX telephone system. The gateway networks 
communicate with each other over an internet protocol (IP) network, such as a wide area 
network (WAN) Network 1 and over the public switched telephone network (PSTN) 2. 

In gateway network 10, a gateway server 1 1 operates in conjunction with a PBX 
telephone system 12, coordinating both PBX telephone calls and public switched 

25 telephone network calls. Gateway networks are described in, for example, commonly 
assigned co-pending U.S. Pat. Application 09/061,802, which is incorporated herein by 
reference. 

Gateway network 20, includes an IP/PBX telephone system 23 that supports IP 
telephones (not shown) which can be either stand-alone devices or incorporated into 
30 computer work stations. The gateway server 21 coordinates the activities of all the 
company-internal telephone systems: the PBX telephone system 22 and the IP/PBX 

-8- 
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telephone system 23. This gateway network 20 configuration is of particularly useful 
where both PBX and IP telephones are used. 

In gateway network 30 has an IP/PBX telephone system 33 is present but no PBX 
telephone system. This situation is particularly useful for a small branch office for which 
5 a conventional PBX would be either impracticable or prohibitively expensive. In this 
configuration the gateway server 3 1 is configured quite differently than in the above 
configurations. Namely, the gateway server 31 includes telephony cards that are 
configured to communicate directly with the PSTN. The gateway server 3 1 coordinates 
the activities the IP/PBX telephone system 33, including its IP telephones and the call 

1 0 routing of said telephones. The gateway server 3 1 may coordinate with another gateway 
server 11,21, in order to provide full services to the users in its network, including for 
example, PBX-based voice-mail. 

FIG. 2 shows a more detailed architecture of gateway network 20 of FIG. 1 . The 
gateway server 21 includes gateway server software 111, a PBX CTI (Computer 

1 5 Telephony Integration) driver 1 1 2, a station/trunk driver 1 1 3 and a VoIP (Voice over IP) 
driver 1 14. The gateway server software 1 1 1 manages call set up and routing, access to 
a directory server 28, user graphical user interface (GUI) updates via a web server, and 
queries and updates to a database of user profiles and call information. In addition, the 
gateway server software 1 1 1 contains an IP/PBX CTI driver 115, which is a piece of 

20 interface software used whenever an IP/PBX call manager 40 is addressed. In the 
remainder of the description, this piece of software, the IP/PBX CTI driver 115, is 
implicitly assumed to be involved with every interaction between the gateway server 
software 1 1 1 and the IP/PBX call manager 40 and therefore, for simplicity, will not be 
shown in the other drawings. The IP/PBX CTI driver 1 15 is implemented so as to adhere 

25 to various interface standards, including by not limited to the Microsoft-touted standard 
TAPI (Telephony Application Programming Interface). 

The gateway server software 1 1 1 uses the PBX CTI driver 1 1 2 software to support 
advanced call control and voice-mail access functions. The PBX CTI driver 1 1 2 software 
is typically supplied by (and is specific to) the PBX vendor. The PBX CTI driver 1 12 

30 communicates with the PBX 30 via the local area network (LAN) 3 connection. The 
station/trunk driver 1 1 3 consists of hardware and software that manage a trunk interface 
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and an analog station interface to the PBX 30. The VoIP driver 1 14 consists of hardware 
and software that handles the conversion between the voice data in the format required 
for the station/trunk driver 1 13 telephony interface and the IP packet format required by 
the WAN EP network 1 . The VoIP driver 1 14 is also referred to as simply the gateway, 
5 as converting voice data between the IP and switched circuit network (SCN), such as the 
PSTN, is its' fundamental function. 

The PBX 30 provides the interface to the PSTN 2. Continuing to refer to FIG. 2, 
the PBX telephone system 22 consists of the PBX 30 and one or more PBX telephones 
31. Operation of the PBXs and PBX telephones is well known and is discussed in detail 

10 in co-pending, commonly assigned U.S. patent application number 09/061,802, which is 
incorporated herein by reference. The voice-mail system operates in conjunction with the 
PBX 30. Proper operation of voice-mail server 32, requires CTI driver 1 12. 

FIG. 2 also shows an embodiment of an flVPBX telephone system 23 which is 
managed by a centralized server called the IP/PBX call manager 40 according to the 

1 5 present invention. The IP/PBX call manager 40 may reside on its own server platform (as 
shown), or it may reside on the same platform as the gateway server 21. 

Typically, the users of the IP/PBX telephone system 23 are equipped with one of 
( 1 ) an IP telephone 4 1 , (2) an IP telephone 4 1 and a work station 50, or (3) a work station 
1 50 that has a built-in IP telephone 141. The IP/PBX call manager 40 first receives a call 

20 setup request from an IP telephone user who initiates a call on the IP telephone 4 1 or 14 1 . 
If the call is for an extension representing another IP telephone 41 or 141 coupled to the 
IP/PBX telephone system 23 , the IP/PBX call manager 40 connects the two IP telephones 
so the call can take place. To set up the connection the IP/PBX call manager 40 
exchanges information with the gateway server software 111 including caller ID 

25 information (normally stored at the gateway server 2 1 ). In addition, the gateway server 
software 1 1 1 can log the start of the call to a call log (not shown). If a call is initiated 
with dialed digits that are not known to the EP/PBX call manager 40, then the IP/PBX call 
manager 40 passes the call setup request to the gateway server software 111. The gateway 
server software 1 1 1 then determines how to route the call, sets up the other leg of the call, 

30 and then returns the information to the IP/PBX call manager 40 of the IP address where 
the IP telephone 41 or 141 needs to route the IP packets. 

- 10- 
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Throughout the rest of this description, whenever the term "IP telephone" is used, 
it is understood that this can mean either a stand-alone telephone device or a telephone 
that is built into a workstation, and these two can be used interchangeably when 
discussing the function of an "IP telephone". 
5 Call Routing and Setup for IP Telephone Calls 

There are a number of different paths that must be considered for routing a call 
involving an IP telephone in IP/PBX telephone system. The different routing paths and 
the sequence of steps required to establish these routings are described in the next 
paragraphs. 

10 In FIG. 3 A an in-progress call is shown between an IP telephone operating in the 

local network and a PSTN telephone at a location nearby the gateway network's location. 
Starting with the caller IP telephone 141, the voice data is converted to IP packets there 
and placed onto the LAN where it is received by the VoIP driver 1 14 of the gateway 
server 1 10. At the VoIP driver 1 14, the data is removed from the IP packets and the data 

1 5 decoded from whatever encoding and compression format was applied by the caller EP 
telephone 141 . The voice data is then routed via the station/trunk driver 1 13 to the PBX 
1 30, and the PBX 30 which in turn routes it in an analog format to the PSTN 102 and on 
through to the PSTN telephone 104. 

The voice which travels from the called PSTN telephone 104 to the caller using 

20 IP telephone 141 follows the same path, but goes through the process in reverse; at the 
VoIP driver 1 14, the voice data is encoded and inserted into IP packets. The data from 
the IP packets are extracted and decoded by the IP telephone 141. 

It should be noted that the same routing path would result if the caller is the PSTN 
telephone user and the called party is the IP telephone user. 

25 In considering how a call such as that shown in FIG. 3A is setup, there are two 

variations that may be considered, which will result in different sequences of steps in the 
call setup process. The two variations are (1) when the caller is using the IP telephone 
141 and the called party is using the PSTN telephone 104, and (2) when the caller is using 
the PSTN telephone and the called party is using the IP telephone. 

30 The call setup sequence for the caller using an IP telephone calling to a user of a 

PSTN telephone is shown in FIG. 3B and described in the subsequent text. Note that in 

- 11 - 
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FIG. 3B, and throughout the remainder of the description, the numbered steps are 
illustrated in the figures by arrows labeled with a corresponding number. 

1. User dials on a keypad of the IP telephone 141. The EP telephone 141 
communicates with the IP/PBX call manager 140 to request call setup. (Step 301) 

2. The IP/PBX call manager 140 communicates to the gateway server 
software 111 that call setup is requested by an IP telephone 141. The IP/PBX call 
manager 140 receives the addressing information of the IP telephone 141 in the 
communication. The gateway server software 1 1 1 checks the directory server 28 (shown 
in FIG. 2), and verifies the user's privilege to access the PSTN 2. (Step 302) 

3. The gateway server software 1 1 1 communicates call setup request to the 
station/trunk driver 113. (Step 303) 

4. The station/trunk driver 1 13 communicates the setup request to the PBX 
30. (Step 304) 

5. The PBX 30 dials to the PSTN telephone 104 via the PSTN 102, and the 
calling party answers the telephone. (Step 305) 

6. The gateway server software 1 1 1 configures its VoIP driver 1 14 to begin 
transmitting voice packets to the address of the IP telephone 141. (Step 306) (Note that 
step 306 can be done at the same time as steps 303-305.) 

7. The gateway server software 1 1 1 informs the EP/PBX call manager 140 
that the call is going through and provides the addressing information for its VoIP driver 
114. (Step 307) 

8. The EP/PBX call manager 140 informs the IP telephone 141 that the call 
is going through and passes the addressing information for the VoIP driver 1 14. The IP 
telephone is then ready to begin transmitting voice packets to the VoIP driver 1 14. (Step 
308) 

The call setup sequence for the caller using a PSTN telephone 1 04 calling to a user 
of an IP telephone 141 is shown in FIG. 3C and described in the subsequent text. 

1. A user of the PSTN telephone 104 dials an IP telephone user at the 
company facility with a direct inward dialing (DID) number. The call is routed via the 
PSTN 102 to the PBX 130. (Step 401) 

2. The PBX 30 routes the call to the station/trunk driver 1 13. (Step 402) 

- 12- 
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3. The station/trunk driver 1 13 routes the call setup request to the gateway 
server software 111. (Step 403) 

4. The gateway server software 1 1 1 checks its database and finds that the user 
being dialed has an IP telephone managed by the IP/PBX call manager 140. The gateway 

5 server software 1 1 1 routes the call setup request to the IP/PBX call manager 140, and it 
attaches the addressing information of its VoIP driver 114, since the gateway server 
software 1 1 1 determines that the voice stream will need to be routed via that driver. (Step 
404) 

5. The IP/PBX call manager 140 finds that the particular EP telephone 141 is 
1 0 not currently in use, and thus forwards the call setup request, along with the addressing 

information of the VoIP driver 114, to the IP telephone 141. The IP telephone 141 
configures itself to begin routing IP voice packets to the VoIP driver 1 14 in the event that 
the called party answers the call. (Step 405) 

6. The IP/PBX call manager 140 sends and acknowledgment back to the 
1 5 gateway server software 111, including the addressing information of the IP telephone 

141. (Step 406) 

7. The gateway server software 111 commands its VoIP driver 114 to 
configure itself to begin sending voice packets to the IP telephone 141. (Step 407) 

8. The gateway server software 1 1 1 configures the station/trunk driver 1 1 3 
20 to route the voice stream to the VoIP driver 1 14. (Step 408) 

FIG. 4A shows the call routing for a telephone call made between a PBX 
telephone and an IP telephone in the same locale. 

FIG. 4B shows the call setup sequence for a telephone call made from an IP 
telephone to a PBX telephone in the same locale. The call setup sequence is as follows: 
25 1 . A user of the IP telephone 1 4 1 dials, and the IP telephone 141 sends a call 

setup request to the EP/PBX call manager 140. (Step 501) 

2. The IP/PBX call manager 140 receives the call setup request and forwards 
it to the gateway server software 111. (Step 502) 

3. The gateway server software 1 1 1 checks its database and finds the called 
30 party has a PBX telephone 1 3 1 , so it sends a call setup request to the station/trunk driver 

113. (Step 503) 
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4. The station/trunk driver 1 13 forwards the call setup request to the PBX 
130. (Step 504) 

5. The PBX 130 calls the PBX telephone 1 3 1 of the called party. (Step 505) 

6. The gateway server software 1 1 1 configures its VoIP driver with the 
5 address of the IP telephone 141, and the VoIP driver gets ready to start transmitting voice 

IP packets to that address. (Step 506) 

7. The gateway server software 1 1 1 responds back to the IP/PBX call 
manager 140 that its part of the call has been successfully setup, and it forwards the 
address of its VoIP driver 1 14. (Step 507) 

10 8. The IP/PBX call manager 140 responds to the IP telephone 141, 

forwarding it the address of the VoIP driver 1 14. The IP telephone 141 then configures 
itself to begin routing IP voice packets to the VoIP driver 1 14. (Step 508) 

The call setup sequence for the caller using a PBX telephone calling to a user of 
an IP telephone is shown in FIG. 4C and described in the subsequent text. 

15 1 . A user of the PBX telephone 13 1 dials an IP telephone user at the same 

company facility using the extension only to dial, or using an on-net number. The call is 
routed to the PBX 130. (Step 601) 

2. The PBX 30 routes the call to the station/trunk driver 1 13. (Step 602) 

3. The station/trunk driver 113 routes the call setup request to the gateway 
20 server software 111. (Step 603) 

4. The gateway server software 1 1 1 checks its database and finds that the user 
being dialed has an IP telephone managed by the IP/PBX call manager 140. The gateway 
server software 1 1 1 routes the call setup request to the IP/PBX call manager 140, and it 
attaches to the request the addressing information of its VoIP driver 114, since the 

25 gateway server software 1 1 1 determines that the voice stream will need to be routed via 
that driver. (Step 604) 

5. The IP/PBX call manager 140 finds that the particular IP telephone 141 is 
not currently in use, and thus forwards the call setup request, along with the addressing 
information of the VoIP driver 114, to the IP telephone 141. The IP telephone 141 

30 configures itself to begin routing IP voice packets to the VoIP driver 1 14 in the event that 
the called party answers the call. (Step 605) 

- 14- 



WO 01/06740 



PCTYUSOO/19209 



6. The IP/PBX call manager 140 sends an acknowledgment back to the 
gateway server software 111, including the addressing information of the IP telephone 
141. (Step 606) 

7. The gateway server software 111 commands its VoIP driver 114 to 
configure itself to begin sending voice packets to the IP telephone 141. (Step 607) 

8. The gateway server software 1 1 1 configures the station/trunk driver 1 1 3 
to route the voice stream to the VoIP driver 1 14. (Step 608) 

FIG. 5A shows the call routing for a telephone call made between one IP 
telephone 141 and another IP telephone 241 in the same locale. 

FIG. 5B shows the call setup sequence for a telephone call made from one IP 
telephone 141 to another IP telephone 241 in the same locale. 

1. A user of the IP telephone 141 dials, and the DP telephone 141 sendsacall 
setup request to the IP/PBX call manager 140. (Step 701) 

2. The IP/PBX call manager 140 receives the call setup request and forwards 
it to the gateway server software 111. (Step 702) 

3 . The gateway server software 1 1 1 checks its database and finds that the user 
being dialed has an IP telephone 241managed by the IP/PBX call manager 140. The 
gateway server software 111 provides the addressing information to the IP/PBX call 
manager 140. (Step 703) 

4. The IP/PBX call manager 140 begins routing IP voice packets to the IP 
telephone 241 (Step 704) and to IP telephone 141 (Step 705). 

FIG. 5C shows an alternate (and less preferred) call setup sequence for a telephone 
call made from one IP telephone 141 to another IP telephone 241 in the same locale. 

1 . A user of the IP telephone 1 4 1 dials, and the IP telephone 1 4 1 sends a call 
setup request to the EP/PBX call manager 140. (Step 801) 

2. The IP/PBX call manager 140 receives the call setup request and finds that 
the user being dialed has an IP telephone 241managed by the IP/PBX call manager 140. 
(Step 802) 

3. The EP/PBX call manager 140 provides the addressing information to IP 
telephone 1 4 1 , and IP telephone 1 4 1 begins routing IP voice packets to IP telephone 24 1 . 
(Step 803) 
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FIG. 6A shows the call routing for a telephone call made between a PSTN 
telephone 104 and an IP telephone 241, with the two telephones in different locales. 

FIG. 6B shows the call setup sequence for a telephone call made from an IP 
telephone 241 to a PSTN telephone 104, with the two telephones in different locales. 

1 . A user of the IP telephone 14 1 dials, and the IP telephone 1 4 1 sends a call 
setup request to the IP/PBX call manager 140. (Step 901) 

2. The IP/PBX call manager 1 40 receives the call setup request and forwards 
it to the gateway server software 111. (Step 902) 

3 . The gateway server software 1 1 1 checks its database and finds that the user 
being dialed has a PSTN telephone 104 nearby another gateway network 110. The 
gateway server software 2 1 1 connects to gateway server software 1 1 1 in the other gateway 
network via the WAN 101. (Step 903) 

4. The gateway server software 111 sends a call setup request to the 
station/trunk driver 113. (Step 904) 

5. The station/trunk driver 1 13 forwards the call setup request to the PBX 
130. (Step 905) 

6. The PBX 1 30 calls the PSTN telephone 1 04 of the called party. (Step 906) 

7. The gateway server software 1 1 1 configures its VoIP driver with the 
address of the IP telephone 141, and the VoIP driver gets ready to start transmitting voice 
EP packets to that address. (Step 907) 

8. The gateway server software 1 1 1 responds back to the gateway server 
software 211 that its part of the call has been successfully setup, and it forwards the 
address of its VoIP driver 214. (Step 908) 

9. The gateway server software 2 1 1 forwards the address of its VoIP driver 
214 to the IP/PBX call manager 240. (Step 909) 

10. The IP/PBX call manager 240 responds to the IP telephone 241, 
forwarding it the address of the VoIP driver 214. The IP telephone 241 then configures 
itself to begin routing IP voice packets to the VoIP driver 1 14. (Step 910) 

FIG. 6C shows the call setup sequence for a telephone call made from a PSTN 
telephone 104 to an IP telephone 241, with the two telephones in different locales. 

1 . A user of the PSTN telephone 104 dials and sends a call setup request to 
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the PBX 130 via the PSTN 102. (Step 1001) 

2. The PBX 130 routes the call to the station/trunk driver 1 13. (Step 1002) 

3. The station/trunk driver 113 routes the call setup request to the gateway 
server software 111. (Step 1 003) 

5 4. The gateway server software 1 1 1 checks its database and finds that the user 

being dialed has a PSTN telephone 104 nearby another gateway network 210. The 
gateway server software 1 1 1 connects to gateway server software 2 1 1 in the other gateway 
network via the WAN 101. (Step 1004) 

5 . The gateway server software 2 1 1 checks its database and finds that the user 

1 0 being dialed has an IP telephone managed by the IP/PBX call manager 240. The gateway 
server software 2 1 1 routes the call setup request to the IP/PBX call manager 240, and it 
attaches to the request the addressing information of its VoIP driver 214, since the 
gateway server software 21 1 determines that the voice stream will need to be routed via 
that driver. (Step 1005) 

15 6. The IP/PBX call manager 240 responds to the IP telephone 241, 

forwarding it the address of the VoIP driver 214. The IP telephone 241 then configures 
itself to begin routing IP voice packets to the VoIP driver 1 14. (Step 1006) 

7. The IP/PBX call manager 240 sends an acknowledgment back to the 
gateway server software 211, including the addressing information of the IP telephone 

20 241. (Step 1007) 

8. The gateway server software 21 1 responds back to the gateway server 
software 1 1 1 that its part of the call has been successfully setup, and it forwards the 
address of its VoIP driver 114. (Step 1008) 

9. The gateway server software 1 1 1 configures its VoIP driver 1 14 with the 
25 address of the IP telephone 24 1 , and the VoIP driver gets ready to start transmitting voice 

IP packets to that address. (Step 1009) 

FIG. 7A shows the call routing for a telephone call made between a PBX 
telephone 131 and an IP telephone 241, with the two telephones in different locales. 

FIG. 7B shows the call setup sequence for a telephone call made from an IP 
30 telephone 24 1 to a PBX telephone 131, with the two telephones in different locales. 

1 . A user of the IP telephone 24 1 dials, and the IP telephone 24 1 sends a call 
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setup request to the BP/PBX call manager 240. (Step 1101) 

2. The EP/PBX call manager 240 receives the call setup request and forwards 
it to the gateway server software 211. (Step 1 1 02) 

3 . The gateway server software 2 1 1 checks its database and finds that the user 
being dialed has a PBX telephone 131 managed by another gateway network 1 10. The 
gateway server software 2 1 1 connects to gateway server software 1 1 1 in the other gateway 
network via the WAN 101. (Step 1 103) 

4. The gateway server software 111 sends a call setup request to the 
station/trunk driver 113. (Step 1 1 04) 

5. The station/trunk driver 1 13 forwards the call setup request to the PBX 
130. (Step 1105) 

6. The PBX 1 30 calls the PBX telephone 1 3 1 of the called party. (Step 1 1 06) 

7. The gateway server software 1 1 1 configures its VoIP driver 1 14 with the 
address of the IP telephone 24 1 , and the VoEP driver gets ready to start transmitting voice 
IP packets to that address. (Step 1 107) 

8. The gateway server software 1 1 1 responds back to the gateway server 
software 211 that its part of the call has been successfully setup, and it forwards the 
address of its VoIP driver 1 14. (Step 1 108) 

9. The gateway server software 2 1 1 forwards the address of its VoIP driver 
214 to the IP/PBX call manager 240. (Step 1 109) 

10. The IP/PBX call manager 240 responds to the IP telephone 241, 
forwarding it the address of the VoIP driver 214. The IP telephone 241 then configures 
itself to begin routing IP voice packets to the VoIP driver. (Step 1 1 10) 

FIG. 7C shows the call setup sequence for a telephone call made from a PBX 
telephone 13 1 to an IP telephone 241, with the two telephones in different locales. 

1 . A user of the PBX telephone 1 3 1 dials and sends a call setup request to the 
PBX 130. (Step 1201) 

2. The PBX 130 routes the call to the station/trunk driver 1 13. (Step 1202) 

3. The station/trunk driver 1 13 routes the call setup request to the gateway 
server software 111. (Step 1 203) 

4. The gateway server software 1 1 1 checks its database and finds that the user 
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being dialed has an IP telephone 241 managed by another gateway network 210. The 
gateway server software 111 connects to gateway server software 2 1 1 in the other gateway 
network via the WAN 101. (Step 1204) 

5 . The gateway server software 2 1 1 checks its database and finds that the user 
5 being dialed has an IP telephone managed by the IP/PBX call manager 240. The gateway 
server software 2 1 1 routes the call setup request to the IP/PBX call manager 240, and it 
attaches to the request the addressing information of its VoIP driver 214, since the 
gateway server software 21 1 determines that the voice stream will need to be routed via 
that driver. (Step 1205) 
10 6. The IP/PBX call manager 240 responds to the IP telephone 241, 

forwarding it the address of the VoIP driver 214. The IP telephone 241 then configures 
itself to begin routing IP voice packets to the VoIP driver 1 14. (Step 1206) 

7. The IP/PBX call manager 240 sends an acknowledgment back to the 
gateway server software 211, including the addressing information of the IP telephone 

15 241. (Step 1207) 

8. The gateway server software 21 1 responds back to the gateway server 
software 1 1 1 that its part of the call has been successfully setup, and it forwards the 
address of its VoIP driver 1 14. (Step 1208) 

9. The gateway server software 1 1 1 configures its VoIP driver 1 14 with the 
20 address of the IP telephone 24 1 , and the VoIP driver gets ready to start transmitting voice 

EP packets to that address. (Step 1209) 

FIG. 8A shows the call routing for a telephone call made between one IP 
telephone 1 4 1 and another IP telephone 24 1 , with the two telephones in different locales. 
FIG. 8B shows the call setup sequence for a telephone call made from one EP 
25 telephone 141 to another IP telephone 241, with the two telephones in different locales. 

1 . A user of the IP telephone 24 1 dials, and the IP telephone 24 1 sends a call 
setup request to the IP/PBX call manager 240. (Step 1301) 

2 . The IP/PBX call manager 240 receives the call setup request and forwards 
it to the gateway server software 211. (Step 1302) 

30 3 . The gateway server software 2 1 1 checks its database and finds that the user 

being dialed has an IP telephone 141 managed by another gateway network 1 10. The 
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gateway server software 2 1 1 connects to gateway server software 1 1 1 in the other gateway 
network via the WAN 101. (Step 1303) 

4. The gateway server software 1 1 1 sends a call setup request to the IP/PBX 
call manager 140. (Step 1304) 
5 5. The IP/PBX call manager 140 forwards the call setup request to the EP 

telephone 141. (Step 1305) 

6. The gateway server software 1 1 1 responds back to the gateway server 
software 211 that its part of the call has been successfully setup, and it forwards the 
address of its VoIP driver 1 14. (Step 1306) 
1 0 7. The gateway server software 2 1 1 forwards the address of its VoIP driver 

214 to the IP/PBX call manager 240. (Step 1307) 

8. The IP/PBX call manager 240 responds to the IP telephone 241, 
forwarding it the address of the VoIP driver 214. The EP telephone 241 then configures 
itself to begin routing EP voice packets to the VoIP driver. (Step 1308) 

15 

Features 

In this section we discuss the various features that can be provided features to 
users of IP telephones 141,241, coupled to the IP/PBX telephone system 3 3 in accordance 
with an embodiment of the present invention. Many of these features are also described 
20 in co-pending, commonly assigned U.S. patent application number 09/06 1 ,802, which is 
incorporated herein by reference. 
Automated Call Control Features 

Quality of Service Monitoring 

As discussed in co-pending, commonly assigned U.S. patent application number 
25 09/061,802, which is incorporated herein by reference, there are quality of service 
indicators which are placed in the IP voice packets at the time when the packets are 
generated in preparation for routing onto the LAN. At the later point in the call path 
routing, when the data in the IP packets are extracted and decoded, the quality of service 
indicators are assessed to determine if a reasonable quality for the voice conversation is 
30 being maintained. In U.S. patent application number 09/06 1 ,802, the VoIP call routing 
paths and the voice IP packets are generated/encoded by the VoIP driver 1 14 in one 
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gateway server 1 10 and extracted/decoded by the VoIP driver in another gateway server 
120. 

With the introduction of the IP/PBX telephone system 33, the quality of service 
(QoS) determination may involve two separate legs of the IP network. For example, 
5 consider the call path shown in FIG. 9A; the voice IP packets that are generated at the IP 
telephone 241 are de-packetized/decoded at the VoEP driver 1 14. Thus, it is important 
that the multiple vendors agree on the required QoS threshold. Assuming that both the 
VoIP driver vendor and the IP telephone vendor agree on how to use QoS, then an 
assessment must be made as to where in the call path the quality degradation is taking 
1 0 place. If it is determined that the degradation is occurring on the WAN IP Network 101, 
(as opposed to on the LAN), then the communication stream currently using the WAN IP 
Network can be moved out onto the PSTN 102, fallback to PSTN, as is described below 
and in U.S. patent application number 09/061,802, which is incorporated herein by 
reference. 

1 5 In order to detect a problem of the WAN, the VoIP driver 1 14 of the invention 

continues to monitor QoS for the entire path segment over which voice IP packets travel. 
For example, referring to FIG. 9A, the VoIP driver 114 monitors the QoS of packets 
generated at IP telephone 241. If the QoS for this entire segment degrades to a given 
threshold, the VoIP driver communicates this to the gateway server software 111. The 

20 gateway server software 1 1 1 then initiates a secondary simple test of the QoS between the 
two gateway servers (the gateway server 210 of the caller and the gateway server 1 10 of 
the called party). This secondary test may involve sending bursts of IP packets over the 
WAN IP network 101 and having the VoIP drivers 1 14 and 214 on either end assess the 
QoS. Alternatively the test may be more simplistic, such as issuing a series of "ping" 

25 commands across the WAN IP network 101, between the two gateway servers 1 1 0 and 
210. If the secondary QoS test indicates performance degradation on the WAN 101 , then 
fallback to PSTN is initiated. If the secondary QoS indicates no degradation, then the 
problem is on the LAN. In this case there is little that the gateway server can do to 
alleviate said problem, other than alarm to an external system, such as a network 

30 management system. Such an alarm, in more sophisticated network configurations, could 
activate load-balancing algorithms which might eliminate high-load network activities or 
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users. 

Fallback to PSTN 

Five different methods for the fallback to PSTN are discussed in co-pending, 
5 commonly assigned U.S. patent application number 09/061,802, which is incorporated 
herein by reference, page 44 line 1 through page 49 line 3 1 . The differences between the 
methods are related primarily to the variations in PBX configurations. In considering how 
a fallback would be enacted in a VoIP call routing path involving an IP telephone, 
reference FIG. 9A. The methods in U.S. patent application number 09/061,802, are the 

1 0 same when applied to the PBX telephone user at one end of the call. For the IP telephone 
user at the other end of the call, some additional method must be described. 

Consider that FIG. 9A illustrates an original VoIP call involving an IP telephone 
241, and that FIG. 9B illustrates the modified call path once the fallback to PSTN 
operation has been completed. The path of the call now flows from PBX telephone 13 1 

15 at a first location through the PBX 130, loops through the station/trunk driver 1 13 and 
back into the PBX 130 (using a second port in the PBX 130) and out into the PSTN 102. 
The PSTN 102 at the second site feeds the call into PBX 230 and then into station/trunk 
driver 213, where it is routed through VoIP driver 2 1 4 and finally on to the IP telephone 
241. 

20 One way that the fallback to PSTN operation can be accomplished is as follows. 

The sequence of events starts when the VoIP driver 1 14 in gateway server 110 detects 
QoS degradation on the call path (between VoIP driver 1 14 and IP telephone 214), and 
gateway server software 1 1 1 is notified of this issue. Next, gateway server software 1 1 1 
coordinates the execution of a secondary test by exchanging packets between its VoIP 

25 driver 1 14 and the VoIP driver 214 of the gateway server 210. This test again indicates 
serious degradation, so the gateway server software 1 1 1 initiates a fallback to PSTN. First 
it announces its intention via a notification sent to the caller gateway server software 211. 
The caller gateway server 210 then coordinates with the called gateway server 1 10 to 
setup a PSTN call between the two gateway servers 1 10 and 210 via the PBXs 130 and 

30 230. (Further details of this can be found in co-pending, commonly assigned U.S. patent 
application number 09/061,802, at page 46, line 24 through page 47, line 1 1) As soon 
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as the PSTN call is setup between the two gateway servers, the gateway server software 
211 must command the IP telephone 241, via its associated IP/PBX call manager 240, 
to start routing its packets to the local VoIP driver 214 instead of the remote VoIP driver 
1 14. The modified call path is now complete and the users' conversation can continue. 

5 

Multiple IP/PBX System Vendors Supported 

The invention supports more than one equipment vendor for the IP/PBX system 
33. For example, the vendor of the EP/PBX system 33 associated with one gateway 
network 20 may differ from the vendor of the IP/PBX system associated with another 
1 0 gateway network 30. To accomplish this both IP/PBX systems must support and be using 
the same kind of encoding and compression algorithms and they must further support the 
same voice over IP protocol, for example H.323. 

Usability Features 

15 Direct Inward Dialing for IP Telephone Users 

The gateway server 31 of the present invention, with its tight integration to the 
PBX 30, and its ability to coordinate call setup with the EP/PBX call manager 40 of the 
IP/PBX telephone system 33, also provides a unique capability to support direct inward 
dialing (DID) to the IP telephone users. Current IP/PBX telephone systems 33 support 

20 a direct inward dialing capability only via another specialized piece of equipment which 
must be separately purchased. A cheaper solution, made possible by the gateway server 
of the present invention, is to configure phantom PBX ports (not shown) on the PBX 30. 
A PSTN phone number is associated with a PBX phantom port for each IP telephone user, 
and (as the PBX 30 has already been configured to operate with the gateway server 20, 

25 30), all calls incoming from the PSTN 2 are routed from the phantom port to the gateway 
server 20, 30. The gateway server 20, 30, maintains the association of the PBX DID 
phone number to the IP telephone extension, and thus routes the call to the IP/PBX call 
manager 40 for processing, and the IP/PBX call manager in turns routes the call to the IP 
telephone. In the event that the IP/PBX call manager determines that the IP telephone 4 1 

30 is for some reason unavailable, i.e. the user may already be engaged in a telephone 
conversation, then the gateway server 20, 30 of the present invention further provides 
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voice-mail capability for the IP telephone user. 
Unified Voice-mail 

The current integration implementation of IP/PBX telephone systems with PBX 
telephone systems has a major drawback in that separate voice-mail systems are used for 
the IP telephone users and the PBX telephone users. For example, the users of the PBX 
telephones use the PBX-associated voice-mail. For PBX voice-mail, there are currently 
two major vendors, Octel and Audix, which have both been in the business for a long time 
and have quite matures products. For the IP-based voice-mail, there is less 
standardization, and the available products are less mature and do not scale as well as the 
PBX voice-mail products do. Having two different voice-mail systems at the same 
company site creates problems for the users. For example, a user cannot forward voice- 
mail between the systems, and the voice-mail features and commands are likely to differ 
between the different systems. Furthermore, the multiple voice-mail systems require 
separate system administration for the each different voice-mail system. 

The invention solves this problem by allowing all users, including the IP/PBX 
telephone users, access to the fully scalable and mature PBX voice-mail system. The 
system of the invention can be configured to automatically re-route to the PBX voice-mail 
if the IP/PBX telephone user does not pick up after a certain number of rings (such as 4 
or 5), or if the called party is otherwise unavailable. The method of implementation 
involves assigning each IP telephone user a port in the PBX telephone system. Since the 
port is not physically connected with a telephone, it is termed a "phantom" port. 

FIG. 10A shows a sample call setup flow for a call attempt from a caller PBX 
telephone 130 to the called IP telephone 141, where the IP telephone 141 is found to be 
busy, and the call is thus routed to the called party's voice-mail system 125. Both caller 
and called parties are located at the same site and associated with the same gateway server 
110. 

1 . A user at the caller PBX telephone 1 3 1 dials to the called IP telephone 141 
user at the same company facility using the extension to dial. The call is routed to the 
PBX 130. (Step 1401) 

2. The PBX 1 30 finds that the called number corresponds to an extension it 

-24- 



WO 01/06740 



PCT/USOO/19209 



manages, so it routes to that extension' s port. The called party ' s port (actually a phantom 
port with no telephone attached) is configured to automatically forward all calls over to 
the gateway server 1 10, so the call is routed to the station/trunk driver 1 13. (Step }402) 

3. The station/trunk driver 1 13 routes the call setup request to the gateway 
5 server software 111. (Step 1403) 

4. The gateway server software 1 1 1 checks its database and finds that the user 
being dialed has an IP telephone 141 managed by the IP/PBX call manager 140. The 
gateway server software 111 routes the call setup request to the EP/PBX call manager 1 40, 
and it attaches to the request the addressing information of its VoIP driver 1 14, since the 

1 0 gateway server software 1 1 1 determines that the voice stream will need to be routed via 
that driver. (Step 1404) 

5. The IP/PBX call manager 140 finds that the particular IP telephone 141 is 
unavailable for use (for example, it may be busy, or a "do not disturb" setting may have 
been enabled by the user). The IP/PBX call manager 140 thus responds back to the 

1 5 gateway server software 1 1 1 that the called IP telephone 141 is unavailable, and thus the 
call cannot be handled. (Step 1405) 

6. The gateway server software 1 1 1 now decides to route the call to the voice- 
mail system, so it first commands the CTI driver 1 12 to reconfigure the PBX 130 so that 
the forwarding of the call on that port goes directly to voice-mail. (Step 1406) 

20 7. The CTI driver 1 12 commands the PBX 130 to reconfigure itself so that 

the forwarding of the call on that port goes directly to voice-mail. (Step 1407) 

8. The gateway server software 1 1 1 commands the station/trunk driver 1 1 3 
to route the call to the PBX 130. (Step 1408) 

9. The station/trunk driver 113 routes the call to the PBX 130. (Step 1409) 
25 1 0. The PBX 1 30 has been configured with a phantom PBX port for the called 

party. Since there is no physical telephone attached to that port, the call is routed directly 
to the voice-mail system 125. (Step 1410) 

1 1 . Meanwhile, the gateway server software 1 1 1 commands the CTI driver 1 1 2 
to have the PBX 1 30 re-configure the phantom port of the called party back to its original 

30 state, which is to forward calls to the gateway server software 111. (Step 141 1) 

12. The CTI driver 1 1 2 commands the PBX 1 30 to re-configure the phantom 
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port of the called party back to its original state. The PBX 130 performs the re- 
configuration, so it is now ready for the next incoming call for that extension. (Step 1412) 
FIG. 10B shows the completed call routing from the caller's PBX telephone to the 
called party's voice-mail. The voice routing is from the caller PBX telephone 131 
5 through the caller's PBX port in the PBX 130, loops through the station/trunk driver 1 13, 
back into the PBX 130, and finally into the voice-mail system 125 via the called party's 
PBX phantom port. 

The case for routing between different sites is somewhat more complex. FIG. 11A 
shows the completed routing of a call made by a PBX user at one site, through the VoIP 

1 0 network, to the voice-mail system of an IP telephone user at a remote site. In more detail, 
the voice routing is from the caller PBX telephone 131 through the caller's PBX port in 
the PBX 130, through the station/trunk driver 1 13 and the VoIP driver 1 14, through the 
WAN IP network 1 0 1 to the other site, through the VoIP driver 2 14 and the station/trunk 
driver 213, to the PBX 230, and finally into the voice-mail system 225 via the called 

1 5 party's PBX phantom port. 

FIG. 1 IB shows a call setup flow corresponding to the voice path shown in FIG. 
11A. The caller at caller PBX telephone 131 makes a call to the called IP telephone 241, 
where the called IP telephone 241 is found to be unavailable, and the call is thus routed 
to the called party's voice-mail system 225. 

20 1 . A user at the caller PBX telephone 1 3 1 dials to the called IP telephone 24 1 

user at a different company facility using an on-net number to dial. The call is routed to 
the PBX 130. (Step 1501) 

2. The PBX 130 routes the call to the station/trunk driver 1 13. (Step 1502) 

3. The station/trunk driver 1 1 3 routes the call setup request to the gateway 
25 server software 111. (Step 1 503) 

4. The gateway server software 1 1 1 checks its database and finds that the user 
being dialed is located at another company facility, under the purview of the gateway 
server 210. The gateway server software 111 forwards the call setup request to the 
gateway server software 211 via the WAN IP network 101. (Step 1504) 

30 5 . The gateway server software 2 1 1 checks its database and finds that the user 

being dialed has an IP telephone managed by the IP/PBX call manager 240. The gateway 
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server software 21 1 routes the call setup request to the IP/PBX call manager 240, and'it 
attaches to the request the addressing information of the VoIP driver 114, since the 
gateway server software 21 1 determines that the voice stream will need to be routed via 
that driver (assuming the called party is available for the call). (Step 1505) 
5 6. The IP/PBX call manager 240 finds that the particular IP telephone 241 is 

currently unavailable, and thus responds back to the gateway server software 211 that the 
called IP telephone 241 is busy, and thus the call cannot be handled. (Step 1506) 

7. The gateway server software 2 1 1 now decides to route the call to the voice- 
mail system 225, so it first commands the CTI driver 212 to reconfigure the PBX 230 so 

1 0 that the forwarding of the call on that port goes directly to voice-mail. (Step 1 507) 

8. The CTI driver 2 1 2 commands the PBX 230 to reconfigure itself so that 
the forwarding of the call on that port goes directly to voice-mail. (Step 1508) 

9. The gateway server software 2 1 1 commands the station/trunk driver 213 
to route the call to the PBX 230. (Step 1 509) 

15 10. The station/trunk driver 213 routes the call to the PBX 230. (Step 1510) 

11. The PBX 230 has been configured with a phantom PBX port for the called 
party. Since there is no physical telephone attached to that port, the call is routed directly 
to the voice-mail system 225. 

12. The gateway server software 2 1 1 configures its VoIP driver 2 14 to begin 
20 routing voice packets to the address of VoIP driver 1 14. (Step 1512) 

13. The gateway server software 211 responds back to the gateway server 
software 1 1 1 with the addressing information of the VoIP driver 214. (Step 1513) 

14. The gateway server software 1 1 1 configures its VoIP driver 1 14 to begin 
routing voice packets to the address of VoIP driver 214. (Step 1514) 

25 15. The gateway server software 1 1 1 configures its station/trunk driver 1 1 3 to 

route the call over to the VoIP driver 1 14. The call routing is now complete. (Step 1551) 
1 6. Meanwhile, the gateway server software 211 commands the CTI driver 212 
to have the PBX 230 re-configure the phantom port of the called party back to its original 
state, which is to forward calls to the gateway server software 211. (Step 1516) 

30 17. The CTI driver 2 1 2 commands the PBX 230 to re-configure the phantom 

port of the called party back to its original state. The PBX 230 performs the re- 
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configuration, so it is now ready for the next incoming call for that extension. (Step 1517) 

FIG. 12 shows how the gateway server 1 10 polls the voice-mail system 125 at 
regular intervals (the interval being configurable) in order to be able to keep the IP 
5 telephone users' telephones current with regard to whether the voice-mail light on the 
phone is on or off. 

1 . The gateway server software 1 1 1 makes a request to the CTI driver 1 1 2 to 
request the status of the voice-mail for a particular user. (Step 1601) 

2. The CTI driver 1 12 passes on the voice-mail status request to the PBX 1 30. 
10 (Step 1602) 

3. The PBX 130 commands the voice-mail server 125 to return the 
information of whether said user has voice-mail in the voice mailbox. (Step 1603) 

4. The voice-mail server 125 responds to the PBX 130 with a yes/no status. 
(Step 1604) 

15 5. The PBX 130 routes the status response back to the CTI driver 1 12. (Step 

1605) 

6. The CTI driver 112 routes the status response to the original requestor of 
the status, the gateway server software 111. (Step 1606) 

7. The gateway server software 1 1 1 maintains the state voice-mail status for 
20 each voice-mail-enabled IP telephone user. It now checks its database to see if the new 

status represents a change from the previous status. If there is no change, the next two 
steps are not executed. If there is a change, the gateway server software 1 1 1 logs the 
change into its database and forwards the status update to the IP/PBX call manager 140. 
(Step 1607) 

25 8 . The IP/PBX call manager 1 40 commands the IP telephone to turn its voice- 

mail indicator light to either ON or OFF, depending on the received status. (Step 1 608) 
Unified Dialing Plan 

The discussion of numbering plans described in co-pending, commonly assigned 
U.S. patent application number 09/061,802, which is incorporated herein by reference, 
30 page 33, line 14 to page 35, line 31 apply equally to the embodiment of the invention 
which includes an IP telephone network. For example, a UNP (unified numbering plan) 

-28- 



WO 01/06740 



PCTYUS00/19209 



or an ETN (enterprise telephone number) scheme can be implemented using the voice 
gateway system of the invention coupled with the IP telephone system. 

A configuration where some users in a network are equipped with IP telephones 
as their primary telephones, while others have PBX telephones, can be handled seamlessly 
5 by the gateway server invention. The dialing plan can be coordinated such that both PBX 
telephone users and IP telephone users at the same site can have the same location ID, 
with possibly different extension ranges. At a site, any user (PBX or IP telephone) can 
call any other user (PBX or IP telephone) using the extension only to dial. Users at other 
enterprise sites make calls to both kinds of telephones, dialing 8 + location ID + extension 
10 (in an ETN scheme), and the callers are not required to know which kind of telephone a 
particular user has. 

Alternatively, if some or all of the IP telephone users are at a small branch site, the 
telephones at the branch site may be configured with a different location ID. The 
invention could then be configured such that users at the main site would be able to dial 

1 5 either 8 + location ID + extension or simply an extension. Having either scheme available 
might be a good transition for an enterprise that is moving toward the more flexible and 
easy to manage ETN type plan. 

The invention implements the dialing plan within the gateway server. 

In one embodiment of the invention, all calls made by IP telephone users to other 

20 IP telephone users in the same IP/PBX telephone system are handled completely within 
the IP/PBX telephone system coordinated by the IP/PBX call manager, while all other 
calls are routed to the gateway server for interpretation or translation. Existing IP/PBX 
telephone systems are generally designed to follow such a scheme, where dialing IP 
telephone to IP telephone is handled within the IP/PBX telephone system by the IP/PBX 

25 call manager (refer to FIG. 2), and such systems typically support different variations for 
how other calls are handled. In fact, the lack of a standard way to handle calls to non-IP 
telephones calling out can create difficulties and complexity for the network administrator 
when integrating an IP telephone system (or multiple IP telephone systems) into the 
existing telephone system. Use of the invention makes this easier, since the dialing plan 

30 for the entire enterprise is coordinated in one place, in the gateway server. 

In another embodiment of the invention, all calls made by IP telephone users are 
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routed by the DVPBX call manager directory into the gateway server for interpretation or 
translation. This preferred embodiment of the invention has the same advantages as the 
previously described embodiment, and furthermore has additional integration advantages, 
including the ability to have a complete and unified call log, and the ability to have a 
5 consistent caller ID format across the enterprise. If not every call goes to the gateway 
server, then the logging done by the gateway server will be missing some calls, which 
renders the call log data less useful. Similarly, if the caller ID information is always 
inserted or appended into the call setup request, as is possible with this preferred 
embodiment, then the format of the caller ID information as well as the actual caller ID 
1 0 data can be maintained in a single central location. The alternative (as would be required 
in the previously described embodiment) would be to maintain caller ID format in the 
both the call manager and the centralized gateway server, and to maintain the IP telephone 
user directory information in both the call manager and in the enterprise directory. 
Caller ED 

15 As described in co-pending, commonly assigned U.S. patent application number 

09/061,802, which is incorporated herein by reference, the integration of the gateway 
server with an enterprise directory provides a central repository for modifying user 
information. User information includes many different attributes describing the particular 
user, including name and office extension number for the user; (refer to "Table 9: White 

20 Pages" in co-pending, commonly assigned U.S. patent application number 09/061,802, 
which is incorporated herein by reference, which shows attributes of user records within 
the directory). Additional attributes are added to support the additional user information 
required to be maintained regarding a user's IP telephone. Table 1 shows a set of 
additional attributes that are used to support the IP/PBX telephone system's inclusion in 
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the gateway server's network. 



AuTlDUte 


uescnpnon 


Primarv Phone Tvne 


Onenf'PBX" "Mobile" or "IP" 


EP/PBX Call Manager- 
Address 


Addressing information of the IP/PBX call manager 
associated with the IP telephone. 


Office IP Phone 
Address 


Addressing information required by the BP telephone 
system to uniquely identify the IP telephone; this may be 
the IP address or other proprietary type of address. 


IP Phone IP Address 


IP address of the user's primary IP telephone. 



10 

Table 1 : New White Pages Attributes for Extended Invention 
On Calls Incoming to IP Telephones 

Since, (in the preferred embodiment of the invention), the call setup for all calls 
made to the IP telephones is done under the coordination of the gateway server software, 
1 5 which accesses the enterprise directory, the caller ID and name display information are 
always added to the incoming call setup request, which flows from the gateway server to 
the IP/PBX call manager to the IP telephone, where it is shown on the IP telephone 
display. 

On Calls Outgoing from IP Telephones 

20 Outgoing calls from the IP telephone can support the caller ID, as long as the call 

is routed to the gateway server, which can then look up the caller ID information in its 
database and forward it to the called party, and the information can thus be displayed as 
described in the invention of co-pending, commonly assigned U.S. patent application 
number 09/061,802, which is incorporated herein by reference. 

25 At Browser Application. Incoming Calls 

Calls which are routed through to either IP telephones or mobile telephones are 
routed through the gateway server. The gateway server has the knowledge as to which 
users currently are logged in to the gateway server via the browser GUI interface on the 
users' PCs. If a browser interface is up for the given user, the gateway server will cause 

30 the browser GUI to display the caller ID and name display information for the call as part 
of a pop-up dialog window. 
Common Caller ID Format 
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A unique advantage of the approach described, for always relying on the caller ID 
and name information to be inserted by the voice gateway invention, is that a common 
format for the identification information can be maintained across several different 
departments and phone systems of an enterprise. 
5 Call Control Features Available at IP Telephone 

Since the IP telephone should be a convenient alternative to having a PBX 
telephone, the same call control features generally available to the PBX telephone user 
should also be available to the IP telephone user. 
Hold/Retrieve 

1 0 If the EP/PBX telephone system supports it, a second call can be routed to the user 

while a call is already in progress. The second call may be signaled to the IP telephone 
user by another ring or by a special tone played over the incoming voice, and the caller 
ID for the new caller may be shown on the display of the IP telephone. If the IP telephone 
user wishes to, he may verbally ask the original caller to hang on, and then dial a 

15 sequence, such as "*5" to put the first caller on hold and answer the new caller. 
Subsequently, the IP telephone user may dial another sequence, such as "*6" to retrieve 
the original and resume that conversation. 
Transfer 

The transfer of a call from the called party using an BP telephone to another caller 
20 in the enterprise can be accomplished by the invention under coordination of the gateway 
server. Consider FIG. 13 A and 12B. FIG. 13A shows a call in progress from a caller on 
a PBX telephone 13 1 to a called party using an IP telephone 141 in the network of the 
same gateway server. FIG. 13B shows the end result of the IP telephone 141 user's action 
to transfer the call to another user at IP telephone 241 within the enterprise. In this case 
25 the second called user is located at another site, and thus the resulting routing is 
accomplished via the IP network 101. 

An example of the steps describing how the transfer of the call is accomplished 
by the system are shown in FIG. 13C and described in the following sequence of steps: 
1 . During a conversation with the caller at PBX telephone 1 3 1 , the called user 
30 at IP telephone 141 determines that the caller should be transferred to speak with a third 
party at IP telephone 241 at another site. So the caller keys a special sequence, such as 
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"*3" followed by the location ID and extension of the third party (on-net dialing), and the 
transfer request is passed on to the IP/PBX call manager 140. (Step 1 701) 

2. The key sequence is interpreted by the IP/PBX call manager 140 which 
forwards the transfer request to the gateway server software 111. (Step 1702) 
5 3 . The gateway server software 1 1 1 forwards the transfer setup request to the 

remote gateway server software 2 1 1 with the given location ID defined in the dialed digits 
and the extension. (Step 1703) 

4. The remote gateway server software 211 checks its database and 
determines that the called party is in its gateway network, and on an IP telephone. The 

10 remote gateway server software 211 makes a call setup request to the EP/PBX call 
manager 240, and passes also the address of the VoIP driver 1 14 of the gateway server 
110. (Step 1704) 

5. The IP/PBX call manager 240 issues a call setup request to the IP 
telephone 241 , which in turns rings the telephone and configures itself to begin shipping 

1 5 voice packets back to the VoIP driver 1 14. (Step 1 705) 

6. The IP/PBX call manager 240 responds back to the gateway server 
software 2 1 1 and includes the addressing information for IP telephone 24 1 . (Step 1 706) 

7. The remote gateway server software 2 1 1 sends a response back to the local 
gateway server software 1 1 1 with the address of the IP telephone 241. (Step 1707) 

20 8. The gateway server software 1 1 1 commands its VoIP driver 1 14 to start 

routing the voice packets to the IP telephone 241. (Step 1708) 

9. The gateway server software 1 1 1 messages to the IP/PBX call manager 140 
that it can take down its leg of the call. (Step 1709) 

10. The IP/PBX call manager 140 relays this information to the IP telephone 
25 1 4 1 , and the user at this telephone now knows that the transfer has completed OK. (Step 

1710) 

Forwarding 

Call forwarding is handled by the gateway server as is discussed in co-pending, 
commonly assigned U.S. patent application number 09/061,802, which is incorporated 
30 herein by reference. The model is easily extended to handle the IP telephones. As an 
example, consider a user who has his "follow-me" configured to route calls first to his IP 
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telephone, and secondly to a secretary's desk. An incoming call is routed by the gateway 
server to the IP/PBX call manager, and in turn to the IP telephone. If after several rings 
the IP telephone user doesn't answer, the EP/PBX call manager stops the ringing and 
routes a negative acknowledgment back to the gateway server. The gateway server 
receives the acknowledgment and then routes the call via PBX to the secretary's desk 
telephone. 
Conferencing 

Call conferencing is also coordinated through the gateway server. If both the 
IP/PBX telephone system and the PBX telephone system support conference calling, then 
conferencing of multiple callers can be supported. FIG. 14 shows an example of a 3-way 
conference call in progress. The first caller at the PBX telephone 131 has called a co- 
worker at an IP telephone 141 (the second party). After their call was established, a third 
party, calling from an IP telephone 241 at a remote office, joins the conversation. In the 
implementation shown, there are three call paths setup. In the integrated system shown, 
each of PBX telephone 131, IP telephone 141, and IP telephone 241 have the capability 
to combine the two incoming voice streams as needed, or select the stream with voice on 
it and provide that to the user. At the PBX telephone 13 1, the CTI driver 1 12 may be 
working with the PBX 130 to implement the conferencing, for example, selecting the 
higher volume of the two incoming voices and patching that voice to the first party. With 
the gateway server invention, the usage protocol for conferencing can be offered in the 
same way for the different kinds of telephone users. 

An alternative implementation of conferences involves the use of a Multipoint 
Conference Unit (MCU) such as that defined by the ITU H.323 standard recommendation. 
Call Control At Browser Application 

Call control features can also be offered to the IP telephone user who is logged 
into the internal network and running the browser application that provides a call control 
interface to the gateway server. The IP telephone may be the user's primary telephone, 
and for convenience, the user may want to control the telephone's features through the 
browser GUI on the user's personal computer. (Refer to co-pending, commonly assigned 
U.S. patent application number 09/06 1 ,802, which is incorporated herein by reference for 
a detailed description.) 
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Refer to FIG. 1 5 , and consider the example of a user clicking on the "Dial" button 
on the PC's browser-based GUI in order to make a call from his IP telephone to another 
user's PBX telephone. This call setup sequence results in the same call routing path as 
that shown already in FIG. 4A. The call setup sequence is defined with the following 
5 steps which are also shown graphically in FIG. 15: 

1 . The user of the PC's browser-based GUI 142 clicks on the "Dial" button. 
The software notifies the web server of the gateway server software 1 1 1 of this event. 
(Step 1801) 

2. The gateway server software 1 1 1 sends a notification to the DP/PBX call 
10 manager 140 that a user associated with one of its IP telephones has just issued a call 

setup request, and it forwards the VoIP driver 1 14 address with the request. (Step 1802) 

3. The EP/PBX call manager 140 forwards the request to dial to the 
appropriate IP telephone 141. The IP telephone 141 then initiates the dialing sequence 
and plays the appropriate feedback tones for the user to hear, and configures itself to begin 

1 5 transmitting IP voice packets to the VoIP driver 1 14. (Step 1 803) 

4. The EP/PBX call manager 140 responds back to the gateway server 
software 1 1 1 with an indication that the call is progressing successfully. (Step 1804) 

5. The gateway server software 1 1 1 checks its database and finds the called 
party has a PBX telephone 131, so it sends a call setup request to the station/trunk driver 

20 113. (Step 1805) 

6. The station/trunk driver 1 13 forwards the call setup request to the PBX 
130. (Step 1806) 

7. The PBX 130 calls the PBX telephone 131 ofthe called party. (Step 1807) 

8. The gateway server software 111 configures its VoIP driver with the 
25 address ofthe IP telephone 141, and the VoIP driver gets ready to start transmitting voice 

IP packets to that address. (Step 1808) 

9. The gateway server software 1 1 1 sends an acknowledgment back to the 
browser-based GUI 142, so it can provide a display update with feedback to the GUI user. 
(Step 1809) 

30 Most of the other major call control functions are handled similarly, by the 

gateway server coordinating with the IP/PBX call manager, and updating the browser GUI 
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at the completion of the operation. The call control functions handled in this manner 
include dial, answer, hold/retrieve, hang up, transfer, and conferencing. It is important 
to note that the IP/PBX telephone system must support this functionality in order to 
provide such call control from the PC. 
5 The "do not disturb" and forwarding functions are handled simply by the browser 

messaging the request to the gateway server. Since both these actions are simply state 
changes that will affect future calls, the gateway server notes this information in its 
database and will use it to make routing decisions when incoming calls arrive for the user. 
Destination Busy Handling At Browser Application 

10 Destination Busy handling features with browser-based GUI control for IP 

telephones can be handled in an equivalent way to what has been described in co-pending, 
commonly assigned U.S. patent application number 09/061,802, which is incorporated 
herein by reference, for PBX telephones. Refer to co-pending, commonly assigned U.S. 
patent application number 09/061,802, which is incorporated herein by reference, page 

15 65 line 1 to page 69 line 1 8. 

In the case where the originator of the call is on an IP telephone and the caller is 
using the PC browser application, and a busy signal is reached at the called party (say the 
called party is on a PBX telephone), the caller is provided with several options by the 
GUI, including (as described in co-pending, commonly assigned U.S. patent application 

20 number 09/061,802, which is incorporated herein by reference) "send alert", "request 
callback", "ring through", and "cancel call"(equivalent to hanging up). 

Each of the options is handled the same way as in co-pending, commonly assigned 
U.S. patent application number 09/061,802, which is incorporated herein by reference, 
except that the "ring through" option to voice-mail is implemented in a slightly different 

25 way, since the voice-mail for the IP telephones is associated with a PBX; this has already 
been discussed earlier in the description. 
Phone Directory At Browser Application 

For IP telephone users, the "white pages" telephone directory associated with the 
browser can be used for convenience when dialing to other users, or when transferring a 

30 call. Refer to co-pending, commonly assigned U.S. patent application number 
09/061,802, which is incorporated herein by reference, for a detailed discussion. 
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Call Log 

The call log is described in co-pending, commonly assigned U.S. patent 
application number 09/061,802, which is incorporated herein by reference, page 64, lines 
10 to 23. 

5 The logging of calls to and from IP telephones follows a similar flow. It is critical 

that the gateway server know when a call is being setup, and when a call is terminated, 
and also when a call changes state (such as when a call is transferred, for example). By 
considering the call setup flows for setup of DP telephone calls described previously, it is 
clear that the gateway server has the knowledge of when calls are initially setup, and thus 

1 0 can write the needed log information for the call initiation event. On the other hand, it is 
not so obvious that the gateway server would be aware of call termination events. For 
example, consider the case of an IP-to-IP telephone call as shown in FIG. 5 A. A call 
could be handled entirely within the IP/PBX telephone system. In order for the call log 
to operate seamlessly regardless of the kind of telephone the various users are operating, 

15 the software object that first discovers that the termination has occurred must send out a 
notification to its controller (i.e. IP/PBX call manager in the case of an IP telephone) 
which the controller must in turn route to the gateway server. 
Follow Me Control 

At Browser Application 

20 As described in co-pending, commonly assigned U.S. patent application number 

09/061,802, which is incorporated herein by reference, there are several options for call 
control. Those discussed relevant to PBX telephones are also relevant to IP telephones. 
Given that the invention can now coordinate multiple types of telephone systems, part of 
the data stored for each user will include which telephone is the primary telephone for the 

25 user. The primary telephone might be the PBX office telephone (the default), or a mobile 
telephone, or an IP telephone. Which telephone is the primary would be entered into the 
gateway server database by a system administrator. This knowledge of the user' s primary 
telephone type is used for "follow-me" routing. The default routing of any incoming call 
for an enterprise user will always be to route it to the primary telephone; if primary 

30 telephone is not answered, the default secondary routing is to voice-mail. However, there 
are several ways that more flexible routing can be enabled. 
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Firstly, users could be given access to modify their "default" routing via the 
browser interface. For example, if a user's default was (1) IP telephone, and (2) voice- 
mail, the user might modify to (1) IP telephone, (2) mobile telephone, and (3) voice-mail. 
Alternatively, only a system administrator might be given the option to modify the 
5 user's default routing. 

Filters can also be stacked one upon the other. For example, a user might have a certain 
filter applied all the time, such as the following: 
Filter ALWAYS_AVOID 

If caller is "ex-husband" then 
1 0 Route to voice-mail . 

End if 

Smart Filters for Follow-Me Scheduling 

Users may be given the ability to setup filters on how to route their calls at certain 
times of the day. For example, the user may want to route directly to voice-mail during 
1 5 nights and weekend times. This can be accomplished by building call filters. A user can 
build up a set of favorite call filters and apply these at different times of the day. For 
example, a software engineer user may want to take only particular calls during the 7:00 
to 9:00 a.m. time frame to guarantee uninterrupted work time. A filter such as the 
following could be constructed by the user, using simple point-and-click methods on the 
20 browser-based GUI: 

Filter UNINTERRUPTED_WORK_TIME 

If caller is one of the following: ("Spouse", "Boss", "Child's School") then 

Route to Primary Office telephone, then Voice-mail. 
Else if caller is ("Customer X") 
25 Route to "Joe Green" 

Else 

Route to Voice-mail 

End 

This filter could then be applied to the hours of 7:00 to 9:00 a.m. in the user's 
30 calendar. 

Integrated OA&M (Operations. Administration, and Maintenance) 
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An advantage of the gateway server is the consistency of service that can be 
provided across the multiple different kinds of telephones, including EP telephones. The 
invention provides a common browser based interface, by which typical O A&M functions 
can be managed from a single point. 
5 User Management 

User management is one of the most common administrative functions which is 
typically carried out on a daily basis at an enterprise. The enterprise directory, which is 
the central point for managing all information about a user or employee, is also used to 
enter all kinds of information regarding usage of different kinds of telephone systems. 

10 For example, an administrator could, from the browser-based GUI, add a new 
employee/user, including name, department info, e-mail address, and the information that 
an IP telephone is the user's primary telephone and secondary telephone is a private 
mobile, the mobile's DD, and what location ID and extension is associated with the user. 
Previous telephone systems have not been integrated in this way. For example, an 

1 5 administrator might have to log into several different systems; a call manager server for 
specifying the IP address, another OA&M monitor for setting up the IP telephone user, 
and so on. 

Alarming and Alarm Monitoring 

The invention supports open standards for alarms, including SNMP. Alarms from 
20 the gateway can be sent to a commercially available network management system, or 
alternatively all alarms can be monitored on the browser-based OA&M monitor. 

It is to be understood that even though numerous characteristics and advantages 
of various embodiments of the present invention have been set forth in the foregoing 
description, together with details of the structure and function of various embodiments 
25 of the invention, this disclosure is illustrative only, and changes may be made in detail, 
especially in matters of structure and arrangement of parts within the principles of the 
present invention to the full extent indicated by the broad general meaning of the terms 
in which the appended claims are expressed. 
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What is claimed is: 

1 . In an EP/PBX telephone system (33) coupled via a gateway server (3 1 ) to a PBX 
( 1 2) having a voice-mail system (125) and a plurality of unused, phantom ports, gateway 
server software (111) comprising: 

means for configuring at least one of the phantom ports on the PBX (12) 
to forward calls directed to the phantom port to an EP telephone (41) via the gateway 
server (31); 

means for receiving a call set up request for a call directed to the phantom 

port; 

means for forwarding the call set up request to the gateway server software 
(1 1 1) in the gateway server (31); 

means for forwarding the call set up request from the gateway server 
software (1 1 1) to an IP/PBX call manager (40) in the EP/PBX telephone system (33); 

means for determining that the IP telephone (4 1 ) is unavailable using the 
IP/PBX call manager (40); 

means for reconfiguring the phantom port on the PBX ( 1 2) to forward calls 
to the voice-mail system (125); and 

means for forwarding the call to the voice-mail system (125). 

2. A system according to claim 1 , wherein the gateway server (3 1 ) comprises a CTI 
driver (115) and wherein the means for reconfiguring the phantom port on the PBX (12) 
comprises the gateway server software (111) having means for instructing the CTI driver 
(1 15) to direct the PBX (12) to reconfigure the phantom port. 

3 . A system according to claim 1 , wherein the means for forwarding the call set up 
request from the gateway server software ( 1 1 1 ) to an IP/PBX call manager (40) comprises 
means for attaching to the call set up request addressing information of a VoIP driver 
(1 14) in the gateway server (3 1). 

4. A system according to claim 1 , wherein the gateway server software (111) further 
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comprises means for restoring the configuration of the phantom port on the PBX (12) to 
forward calls directed to the phantom port to the IP telephone (41). 

5 . A method of pro viding voice-mail to an IP telephone (4 1 ) on an IP/PBX telephone 
5 system (33), the IP/PBX telephone system (33) coupled via a gateway server (3 1) to a 

PBX (12) having a voice-mail system ( 1 25) and a plurality of unused, phantom ports, the 
method comprising steps of: 

configuring at least one of the phantom ports on the PBX (12) to forward 
calls directed to the phantom port to an IP telephone (41) via the gateway server (31); 
1 0 receiving a call set up request for a call directed to the phantom port; 

forwarding the call set up request to gateway server software (1 1 1 ) in the 
gateway server (31); 

forwarding the call set up request from the gateway server software (111) 
to an IP/PBX call manager (40) in the IP/PBX telephone system (33); 
1 5 determining that the IP telephone (41 ) is unavailable using the IP/PBX call 

manager (40); 

reconfiguring the phantom port on the PBX (12) to forward calls to the 
voice-mail system (125); and 

forwarding the call to the voice mail system. 

20 

6. A method according to claim 5, wherein the step of reconfiguring the phantom 
port on the PBX (12) is accomplished using the gateway server software (111). 

7. A method according to claim 6, wherein the gateway server (3 1 ) comprises a CTI 
25 driver (115) and wherein the step of reconfiguring the phantom port on the PBX (12) 

comprises the step of the gateway server software (111) instructing the CTI driver (1 15) 
to direct the PBX (12) to reconfigure the phantom port. 

8. A method according to claim 5, wherein the step of forwarding the call set up 
30 request from the gateway server software ( 1 1 1 ) to an EP/PBX call manager (40) comprises 

the step of attaching to the call set up request addressing information of a VoIP driver 
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(1 14) in the gateway server (31). 



9. A method according to claim 5, further comprising the step of restoring the 
configuration of the phantom port on the PBX (12) to forward calls directed to the 
5 phantom port to the EP telephone (4 1 ). 
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